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Abstract 

A protocol description must be as precise as pos- 
sible in order to avoid multiple subjective and in- 
compatible interpretations by the different imple- 
menters. Natural language (e.g. english) descrip- 
tions are a priori easy to understand but they 
are in general ambiguous. It has been now rec- 
ognized that formal techniques give rise to more 
precise and complete descriptions of software. Es- 
telle is such a formal technique specially designed 
for communication protocols. This paper inves- 
tigates the use of Estelle for describing AX.25 a 
link-level protocol for packet-radio. 


1. Introduction 


The experience has demonstrated that the clear- 
est thing in most natural language protocol descrip- 
tions is their unclearness. This fact has motivated 
protocol designers to develop various description tech- 
niques with theoretical foundations. Among those, 
methods based on Finite State Machines (FSMs) and 
elements of programming language are very popu- 
lar because while being forma? they remain relatively 
easy to understand by any software practitioner. Es- 
telle is a description technique based on FSMs and 
a superset. of Pascal. One of the interests in f stelle 
is its acceptance by many protocol designers and im 
plementers. Estelle is published by the internat ion al 
organization for standardization ISO}. 

Good introductions to Estelle can he found in ref- 
erences 2and 3. To save space, we will mention here 
only the main features of Estelle. A protocol is de- 
scribed in Estelle as a collection of modules. Each 
module is a state machine capable of having mem- 
ory, this is termed Extended FSM (EFSM). Modules 


can communicate with each other as well as with the 
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environment of the specified protocol over channels 
(FIFO queues). Interactions between protocol enti- 
ties (e.g. frames) are communicated in the channels. 
Decomposition of a protocol entity into modules is 
usually functional: a module that defines the transi- 
tion function of the protocol, a module for mapping 
frames into interactions with the environment,, etc. 

The language of Estelle is based on Pascal with 
extensions adapted to protocol specification. A tran- 
sition of a module EFSM is coded using the following 
constructs. The from/to-clauses specify the major 
state change realized by the transition. The depen- 
dence of the transition on an input interaction is ex- 
pressed using a when-clause. A transition without 
a when clause is said spontaneous. A spontaneous 
transition can be used to describe internal decisions 
of the protocol. The condition for firing a transition 
is expressed in a provided-clause. A condition is 
a boolean expression on input. interaction parameters 
and or on inodule context variables. The actions of a 
transit ion are put in a Pascal like begin-end |lock 
Act ions can be for example assignments to cont ext 
variables, calls to procedures or Est elle output st ate. 
ments. A complete specificat ion of a simple link -level 
protocol (the alternating-bit ) can be found jn refer- 
ences land 2. 

The original description of AX.25 packet -radio 
link-layer protocol is written in english’, We intend 
to demonstrate how a higher degree of formalism can 
be obtained with Estelle. A short survey of related 
experiences is given in section 2. Our approach is 


discussed in section 3. We conclude with section 4. 


2. Related Work 


AX.25 is an adapted version of ISO’s HDLC (or 
other similar link level protocols such as CCITT’s 
LAPB). Because of its context of use (over HF, VHF 
or UHF radio channels), AX.25 differs on two main 
points. First, whereas most link-layer protocols as- 
sume a master/slave (DCE/DTE) operation, AX.25 
is a symmetrical protocol. The two entities at. the 
ends of the link are alike, the term DXE is used to 
refer to both devices. Second, each frame ( /, S as 
well as J frames) always identify both the source and 
the destination DXEs. Moreover, to allow repeater 
operation the destination address field may contain a 
route specification that can be made of up to eight, 
repeater-addresses. 

An at tempt to formalize the procedures of HDI.C 
has been realized by Harangozo”. He uses a model 
incorporating regular grammars and a technique of 
indexing. Another met hod. using a model closer to 
Estelle, was used by Bochmann and Chung®". AS 
in Estelle, they use state machines extended with 
context variables and Pascal like statement +. Their 
description provided a basis for an implementation . 
Taylor’ presented a structured approach based on the 
notions of module, FSM and Pascal pseudo-code to 
describe an implementation of AX.25. His concept, 
of module interface is close to the concept of module 
header/body in Estelle. Here we will show the use of 
the formal description technique Estelle to define the 
link-level protocol AX.25. A similar experience with 


Estelle for an application-layer protocol can be found 


in reference 10. 


3. AX.25 Description 


A general approach to protocol description is pre- 
sented in reference 11. The main points that. must 
be covered are context of the specification, protocol 
service, internal structure of the protocol, types of 


exchanged messages and the behavior of the proto- 


col. Those aspects must be defined to a degree nec- 
essary to ensure compatibili ty between AX.25 enti- 
ties but. not further. To save space, a simplified ver- 
sion of AX.25 will be described. It will support. only 
the I (Information), RR (Receive Ready), SABM (Set 
Asynchronous Balanced Mode ). DISC ( Diser nuect Lb 
DM (Disconnected Mode} and UA { Unnumbered 4c 


knowledgment ) frames. 


8.1 General Context 


AX.25 is to be used as a level 2 protocol of ISO's 
seven layers reference model,. Its purpose is t 0 pro- 
vide error free point -to-point communication channels 
between geographically distributed packet-radio com 
puterstations. The protocol is designed to opcrat ¢ 
over low speed high error rate shared radio channels 
(physical-layer). More details about the context can 


be found in reference 4. 


3.2 Protocol Service 


A protocol provides a given service to its users 
(e.g. communication channels }. A protocol service 
is specified in terms of the command types (service 
primitives) available to the user. The service primi- 
tives are abstractly defined. Their physical realization 
in a particular environment (e.g. interrupts, proce- 
dure calls, etc.) is left. to the programmers. 

AX.25 leaves completely open the interface def- 
inition between the protocol and its users. There is 
no explicit. constraint, on the structure of the messages 
and their relative ordering at this interface. The pro- 
tocol defines only the rules for exchanging blocks of 
data (frames) between AX.25 entities over the phys- 
ical layer. This is also the case with specifications of 
HDLC and LAPH. We M-ill t herefore reflect this de- 
signer’s decision by leaving complete freedom on the 


service specification to the implementer. 
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3.3 Structure of the Description 


We structure the functions of the protocol into 
two modules (see figure 1), namely module Abstract 
Protocol (AP) and Transmitter/Receiver (TR). 
The AP module contains the procedures of the link- 
level protocol but. it makes abstraction of frame en- 
coding in terms of bits and bytes. The functions re- 
alized in the TR module are i) encoding/decoding of 
frames, ii) adding/removing of leading and trailing 
flags, iii) computing and adding FCS (Frame-Check 
Sequence) and iv) discarding frames received with in- 
correct FCS, invalid frames and improperly addressed 
frames. We will only consider the definition of the AP 


module. 


AP 
Abstract Protocol 


TR 
Transmitter /Receiver 


Fig. 1 Structure 


3.4 Data Structures 


Blocks of data exchanged between AX.25 protocol 
tuitities are called frames. There are three basic types 
of frames: Unnumbered, Supervisory and Informa hon. 
Each frame consists of a field sequence. 

At the level of the AP module we make abstrac- 
tion of frame encoding in terms of bits and bytes. 
This task is left to the TR module. The interface 
between the AP and TR modules is defined by the 


following channel. 


channel Abstract _Frames-Channel( User,Provider); 
by User out. frame(frame:frame-type); 
by Provider in_frame( frame:frame-type); 


The role of user will be assigned to the AP mod- 
ule, whereas the TR. module will have the role of 


provider. A Pascal variant record is used to the define 
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the frame data type. 


frame-kind = (I,S,U); 
frame-type = record 
case tag:frame_kind of 
I:(4f:1_frame-type); 
S:(sf:$ frame_type); 
U:(uf:U frame_type); 
end 


The list of fields making up each frame kind is 
defined with a record data structure. For example 
the J and {/ frame kinds and their fields are defined 


as: 


Address-type = array {1..7] of char; 

Addressfield = record 

{ repeater operation is not supported } 
destination, source:Address_type; 
end; 

I Control. field = record 
NS.NR:0..7; 

P:boolean; 
end; 

U Control_field = record 
MM:(SABM,DISC,DM,UA); 
P:boolean; 
end; 

PID-field = ( AX25,IP,Addr-res,no_lay-3,esc ); 

Info-field = record 
data: array {0..255] of char; 
length :in teger; 
end; 

I frame_type = record 
Address:Address field; 

Control:1 Control _field; 
PID:PID_field; 

Info :Info_field; 

end; 

U frame_type = record 
Address: Address field; 
Control:U_Control field; 
end; 


S frame structure can be similarly defined. The 
encoding/decoding procedures in the TR modules 
would be defined based on the information provided 
in reference 4. While the encoding rules must be 
strictly respected by the implementer, we generally 
try to leave as much freedom as possible on the se- 
quence of operations to achieve the desired encoding. 
It is therefore expected that a large part of the TR 
module would remain more or less informally speci- 


fied. 


3.5 Abstract Protocol 


In the AP module we will define actions in re- 
sponse to frames from the peer entity and actions 
internally initiated. The interaction point wit lithe 
TR module is named fc and the channel used at this 
point is of type Abstract. Fram ¢s. (‘hannel. The mod- 


ule header would therefore look like: 


module Abstract-Protocol 
(T] :integer; My Address: Address_type); 


abs tract -Frames-Channel: end; 

The Acknowledgement timer T1 value and the 
local DXFaddress are specification parameters. The 
internal behavior of AP is described in the module 
body. In the body declaration part are listed major 
state names under the state statement. 
state sl, s2,....s16; 

This FSM is extended witlh the send and receive 
variables V(S) and V(R). V(S) contains the number 
of the next I frame to send. The number of the next 


expected I frame is kept in V(R). The variables Re- 


moteAddress and Buffer are also defined. 


var VS, VR:0..7; 
RemoteAddress:Address-type; 
buffer:frame_type; 


Pascal procedures are defined for building up 
frames from their parameter values. For example, the 


procedure Format_SABM is defined as: 


procedure Format-SABM( d,s:Address-_type; 
var b:frame-type); 

begin 

with b do begin 
tag:=U; 
uf.Address.destinat ion:=d; uf.Address.source: >. 
uf.Control. MM:=SABM:;: 

end; end; 


The module has the following initializat ion part 


It starts in the major state s/. 


initialize 
to sl 


begin end; 

The possible state changes of AP are defined 
by the transitions. The transition list is divided 
into five sections (phases): disconnected, link-setup, 
disconnect-request, information-transfer and waiting- 
acknowledgement. The disconnected and link-setup 
phases are discussed. 

A disconnected DXE initiates a link setup by 
transmitting a SABM command to the remote DXE, 
starting timer T1 and going to the link-setup phase. 
The Estelle delay-clause is used to model the timer 
Tl. After the module has been in state s2 for T] 
time units, the transition with the delay clause (bel- 
low) is enabled. The implementer determines how 


Remot cAddress is obtained. 


trans 

from sl to s2 

begin 
RemoteAddress:=...; 
Format-SABM( RemoteAddress,My Address,b); 
output fc.out_frame(b); 

end; 


Upon receipt of a SABM command, a discon- 
nected DXE returns a UA response. resets its send 
and receive variables VR and VS to zero and consid. 


ers that the link is setup, i.e.. it enters information- 


transfer phase. 


trans 

from sl to s5 

when fe .in frame 

provided frame.tag= U and 
frame.uf.Control. MM=SABM 

begin 
RemoteAdrress:=frame.uf.Address.destination; 
Format.UA(RemoteAddress,MyAddress,b); 
output fc.out frame(b); 
VR:=0; VS:=O; 

end; 


On receiving a DISC command in the discon- 
nected state, the DXE sends a DM response and re- 


mains in the disconnected state. 


trans 
from sl! to sl 
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when fc.in_frame 
provided frame.tag=U and 
frame.uf.Control. MM=DISC 
begin 
RemoteA drress:=frame.uf.Address.destination; 
Format-DM( RemoteAddress,MyAddress,b); 
output fc.out_frame( b); 
end; 
In the disconnected state, the DXE ignores and 
discards any frame from the remote DXE, except 


SABMs and DISCs. 


trans 

from sl to sl 

when fc.in_frame 

provided not(frame.tag=U and 
(frame.uf.Control. MM=SABM _ or 


frame.uf.Control. MM=DISC)) 
begin end; 


Upon reception of a UA response. in the link- 
setup phase, the local DXE will reset. its send and 
receive variables VS and VR to zero, stop timer T1 
(implicitly realized by the transition) and consider 


that the link is setup. 


trans 
from s2 to s5 
when fc.in_frame 
provided frame.tag=U and 

frame.uf.Control. MM=UA 
begin 

VR:=0; VS:=0; 
end; 

After the DXE has sent the SABM command, if 

a UA or a DM is not correctly received then timer T1 
will run out. The DXE will then resend the SABM 


and will restart timer T1 (implicit). 


trans 

from s2 to s2 

delay (T1) 

begin 
Format_-SABM( R.emoteAddress,MyAddress,b); 
output fc.out -frame( b); 

end; 


The DXE having sent the SABM command will 
ignore and discard any frame from the remote DXE, 


except SABMs, DISCs, or UAs. 
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trans 

from s2 to s2 

when fc.in_frame 

provided not(frame.tag=U and 


(frame.uf.Control. MM=SABM or 
frame.uf.C'ontrol. MM=DISC or 
frame.uf.Control MM=UA)) 
begin end; 
In the link-setup phase, the receipt. of a SABM 
command from the remote DXE will result. in a col- 


lision. The local DXE sends a UA response and con- 


siders that the link is setup. 


trans 
from s2 to s5 
when fc.in_frame 
provided frame.tag=U and 
frame.uf.Control. MM=SABM 
begin 
VR:=0; VS:=0; 


end; 
On the receipt of a DISC command, the DXE 


sends a DM response and enters disconnected phase. 


trans 
from s2 to sl 
when fc.in_frame 
provided frame.tag=U and 
frame.uf.Control. MM=DISC 
begin 
Format-DM( RemoteAddress,MyAddress,b); 
output fc.out-frame(b); 
end; 
Would remain to be specified the disconnect- 
request, information-transfer and waiting- acknowl- 
edgement phases. Those phases are described easily 


in Estelle using the clauses that have been used up to 


now. 


4. Conclusion 


We presented the use of Estelle for describing 
AX.25 a link-level packet-radio protocol. The trans- 
lation in Estelle was made easier because the infor- 
mal description contains transition tables. The tables 


provided a skeleton for the formal specification. The 


AP module gives a high level abstract view of AX.25 
because many details not relevant to the understand- 
ing of the protocol behavior are delegated to the TR 
module. 

Directions for further work would be: i) comple- 
tion of the description in Estelle of AX.25 and ii) eval- 
uation of other formal description techniques, such as 


Lotos!2 or SDL}°, for description of AX.25. 


References 


[1] ISO/TC 97/SC 21, Estelle - A Formal De- 
scription Technique Based on an Extended 
State Transition Model, Draft International 
Standard 9074, 1987. 


[2] M. Barbeau, Estelle: A Formal Description 
Technigu € for Communication Protocols, Pro- 
ceedings of the 6th ARRL Computer Network- 
ing Conference, Redondo Beach, California, 
August. 1987. 


[3] S. Budkowski and P. Dembinski, An Introduc- 
tion to Estelle: A Specification Language for 
Distributed Systems, Computer Net works and 
ISDN Systems. Vol. 14, No. I, 1987. 


[4] T. L. Fox, AX.25 Amateur Packet-Radio Link- 
Layer Protocol, available from ARRL, Newing- 
ton CT USA 06111, 1984. 


5' J. Harangozo. An Approach to Describing a 
Link Level Protocol with a Formal Lanquagq:. 


Proceedings of the Fifth Data Communication 
Symposium, Snowbird, Utah. 1977. 


16] G. V. Bochmann and R. J. Chung, A Formal- 
ized Specification of HDLC Classes of Proce- 
dures, Proceedings of’? the National Telecom- 
munications Conference, Los Angeles, 1977. 


G. ‘I-. Bochmann. A General Transition Model 
for Protocols and Communication Serwces, 
IEEE Transact ion on Communications. Vol. 
C'OM-28, No. 4, April 1980. 


7 


'8] G. V. Bochmann and T. Joachim. Develop- 
ment and Structure Of an X.25 Implementa- 
tion, IEEE Transaction on Software Engineer- 
ing, Vol. SE-5, pp. 429-439, Spet. 1979. 


9] P. Taylor, Design Abstraction for Protocol 
Software, Proceedings of the 6th ARRL Com- 
puter Net working Conference, Redondo Beach, 
California, August) 1987. 


{10} P. D. Amer, F. Ceceli and G. Juanolle, For- 
mal Specification of !SO Virtual Terminal in 
Estelle, Proceedings of IEEE INFOCOM’88, 
New Orleans, Lousiana, March 1988. 


(11] G. V. Bochmann a:nd C. Sunshine, Formal 
Methods in Communication Protocol Design, 
IEEE Transaction on Communications, Vol. 
COM-28, No. 4, April 1980. 


|12] T. Bolognesi and E. Brinksma, Introduction 
to the ISO Specification Language LOTOS, 
Computer Networks and ISDN Systems. Vol. 
14, No. 1, 1987. 


[13] CCITT/SGXI, Functional Specification and 
Description Language, Recommendations 2.101 
to 2.104, 1985. 


15 


